given that the past injections performed on CARM SLOW loop through the automatic script in /virgoDev/Automation/scripts/LSC/inject_lsc.py were not sufficiently accurate (fig.1),  today we increased of a factor 5 the noise amplitude. If this noise amplitude is not enough, we could increase it even further, there should be margin, see fig.2 and 3.

Today the lock acquisition was very troublesome due an excess of noise on the West Green beam. We tried to check the coupling of the fibers on the DAQ room, but it didn't solve the problem. Then we went to the end building and tried to improve the fiber coupling by moving the fibers in the rack. We found a position where the noise was reduced. Still there is some green power missing, so tomorrow some more systematic alignment work will be done, in order to better align the green in the SHG box. After this action the lock acquisition worked properly.

After the earthquake in Japan, we relocked at the first trial and after we arrived LN3_SQZ we started to tune the noise injections for the PSTAB loop (both at LF and HF). After the amplitude of the noise was tuned, we added the corresponding functions into the "injection_SSFS.py" script.

We then proceeded to repeat by hand the two last injections of the SSFS loop, that last shift made the ITF unlock. We decreased slightly their amplitude, while checking that the coherence with Hrec was still high. Now the script launches: CLEAN SSFS_UGF PSTAB_LF PSTAB_HF and then the 4 other SSFS injections at lower frequencies (down to 100 Hz). The operator launched the script and it worked without any problem. Figure 1 shows the injection corresponding to SSFS_UGF, and I think the current UGF is safe enough (I wouldn't push much higher, to ensure robustness, unless the noise injections suggest that it is limiting).

At this point we passed to the DIFFp topic. We started by opening the DIFFp_TX servo loop (which zeros the offset!), and then we started to put back the offset. However this didn't zeroed the new signals and so we continued to increase the offset. During this scan we tried to tune the phase, slightly, even if it was already quite good. Then we repeated the same operation with the TY loop. Figure 2 shows the two scans that we did. For the TY the phases were not clear so we left the deafult ones.

The phases we put are:DIFFp_TX_DCP_HF_mag_B1_phi0 = 0.5;       DIFFp_TX_DCP_mag_B1_phi0 =0.5

Some plots showing the efficiency of the DARM_FREQ clipping in the case of  burst of glitches:

• events of the 2024-04-08 around 17h32m-UTC trend : burst of glitches on NARM and WARN
  • raw at 2024-04-08-17h32m20-UTC  and the zoom where the period with the clipping enabled is highlighted (red rectangle)
  • raw at 2024-04-09-17h37m-UTC
• events of the 2024-04-09 around 14h45-UTC trend:  burst of gliches on WARM only
  • raw  at 2024-04-09-15h48-UTC
• events of the  2024-04-14-23h20m-UTC trend: burst of glitches on NARM and WARM
  • raw at 2024-04-14-23h20-UTC

There is  several single glitches mainly of WARM like the following ones

• 2024-04-15-02h16m22-UTC : trend, raw
• 2024-04-14-22h25m19-UTC: trend, raw
• 2024-04-12-01h55m-UTC: trend, raw_01h57m14-UTC. raw_02h01m23_1s-UTC, raw_02h05m_80s-UTC

After solving the issue of the marionetta of the NI, the ITF started unlocking at acquire LN3. We noticed very fast unlocks, due to the fast shutter closing very soon. No clear loop seemed guilty, but we noticed that the DIFFp TX UGF servo was not working because its line didn't have coherence. However the DIFFp TY gain was increasing quite strongly during the transition. So we increased the gain of the loop to keep the UGF stable, and it seemed to work. We also noticed that the UGF servos were off once in science, even if the lines were ON, so we commented the commands that turn them off.

We left the ITFlocked  in LN3.

The locking troubles were due to an instability at 1.8 Hz of NI marionette reallocation. The problem appears when the correction on the mirror is moved from NI to NE, and at the same time the splitting filters with higher crossover are engaged. Such a problem has never been observed before, but in principle an instability in that region cannot be excluded. There are resonances of the two suspensions which can have slightly different frequency and can create unstable crossing points. Why this problem should appear now, after years of correct work, I don't know. Some measurement is required in order to see if the problem can be explained by a loop model, and a more robust strategy can be found. For the moment, the gain on the filter on MA branch has been changed from the nominal one (0.416) to 0.38. The instability is no more there, but clearly is not very far. Changing more the gain could create different problems, so let's leave the things like that untill a good model will be available.

We prepared and tested the SSFS noise injections:

• 700 Hz - 1000 Hz (ampl: 40)
• 400 Hz - 700 Hz (ampl: 4.8)
• 200 Hz - 400 Hz (ampl: 2.56e-2)
• 100 Hz - 200 Hz (ampl: 1.28e-4)
• 1 kHz - 10 kHz (ampl:10)

The corresponding butterworth flters have been saved in CAL_noise and the process has been restarted. After re-locking the ITF, we tested the inject_SSFS.py script in virgoDev/Automation/scripts/LSC. The test was successful up to SSFS_2, during this injection the ITF unlocked. SSFS_2 and SSFS_3 still need to be tested successfully, the noise injection amplitude is probably too large.

We tested a noise injection on SRCL using the 'SRCL_noise_butter' filter. The filter was not present in ACL_noise filter bank, we introduced it before restarting the process for SSFS. We tested the noise injection with amplitude 6.4e-3 and found good coherence. We saved these parameters in the inject_lsc.py script.

Today we had an unlock (15.45 UTC) very similar to the ones of Monday (1st of april) evening, We asked Paolo to take a look and he noticed that the signal sent to the suspensions (ASC_PR_TX/TY_CORR) got to 0 just before the unlock. We didn't see it because the signal ASC_PR_TX/TY didn't go to 0, so this cleearly pointed towards the safety TRIGGER of the loop, based on the sum of B1p QD2 quadrant. We relaxed it a bit (from 11 to 15).

After the maintenance, we have had mainly two types of unlocks: some at CARM_MC_IR, which we didn't pay much attention since the seismic and wind activity are high. However, every time that we rach CARM NULL 1f we would unlock. We could see many "oscillations" on all the longitudinal loops, the PR angular loops and then saturation of B2 photodiode.

It took some time to understand the reason for these unlocks, but since they were all of them at the same moment Diego remembered that it was the moment when we enagge the CARM slow loop. Indeed it looked like it was oscillating at veyr low frequency, so we increased its gain and it worked (1/1 times, we need to see if this works in the long time). Figure 1 shows the clearest example.

WHile debugging I profited to tune the demodulation phase of MICH and SRCL on DRMI 3F, which was off by 0.2 only, then I checked it at STEP 3, and CARM NULL 3f and it looked well tuned. I also fine tuned the DARM phase in STEP3, which ws off by 0.3.

This doesn't explain the unlocks of yesteday on STEP 2 and STEP 3. We keep on investigating.

Here the Figures I mention in the entry.

Looking at some ALS events of the 2024-03-27 night

• 2024-03-27-04h04m02-UTC :the NARM 157MHz magnitude decrease, for unknown reasons, and reaching a very low level this trigs a glitch in the dFreq corresponding channel
• 2024-03-27-04h23m02-UTC,  2024-03-27-04h33m28-UTC : same comments for the 2 others events : an other at the NEB , the other at WEB

A possible simple patch is to clip the DARM_FREQ signal in a given range when the signal is centered on zero .

This has been implemented in the CEB_ALS server and automated in the ARMS_LOCK metatron node

• the clipping is set to +/-150000Hz  at  the DOWN state of the ARMs_LOCK metatron node
• and it is set to +/-200 at the  state 44 of the ARMs_LOCK metatron node
• this plot and its zoom show the  locking sequence

This plot show the trend of 2 lock sequences, before the automation of this patch

• in green the period with the clipping set  to +/-200
• in red without clipping

There is the glitches on the NArm_ BEAT_dFreq signal during these periods, none on the WArm_BEAT:

• For the period where the clipping is applied, this allows to reduce  the glitches on the mirror correction signals without losing  the lock
• without the clipping, the glitches on the mirror correction signals are greater as expected

Let see if this patch will allow to improve the lock acquistion .

A possible improvement would be to clip the glitches at the  Arms frequency channels (NArm_BEAT_dFreq and WArm_BEAT_dFreq) to reduce the glitches on the CARM and DARM frequency signals

All the Acl servers  (AclISC, AclLC, AclSBE, AclFCoplev, Acl) are running with the v1r23p17 version  since the 2024-03-26-15h20mn-UTC .

The main new features are

• for the Cm commands use to set the ACL object parameters, the numeric parameters can be sent  as integer or double .
• the ACL_SINECOMB_CH keyword to define a comb of lines
• the possibly to to delay the readout of the AclAdcCh objets.

The first trial was done the 2024-03-25  starting at 14H-LT

• all the Acl servers were restarting the Acl v1r22p17 : operation complete around 17h-LT
• upgrade of the INJ Acl server configurations
• Some tuning were done on the NEB and WEB Als servers to avoid missing ADCs sample by adjusting the timing sequence:  the LOOP_DELAY was increased to 6us for NEB and 7us for WEB
• after the recovery of Injection system  and the ITF alignment,  we faced some troubles with the lock sequence 
  • some Cm messages sent  by the Automation servers with the "load" or "apply'  commands  related to ACL_MATRIX_CH or ACL_SUM_CH objects were all rejected by the Acl servers
  • To relock the ITF, the LSC_Acl, ASC_Acl, NEB_ALS_BPC, WEB_ALS_BPC and the SDB1_LC servers were restarted with the Acl v1r20p17 version .  The ITF was relocked at LN3 . Unfortunatly , the SDB1_OMC server was not updated  and the OMC lock sequence was not correctly achieved
• To fix the issue the Acl v1r23p17 was created and deployed on all the Acl servers

After the restart of the INJ Acl server, De Rossi and Gosselin spent a long time recovering the injection.

Once they gave the green light, we continued with the lock acquisition, but noticed that the arms would not engage the lock loop.

Masserot discovered a bug in the current build of Acl that would prevent any "load" command sent to a Sum or Matrix channel. He rolled back the previous version of Acl on every server contacted by the ISC metatron node. He did not do the same thing for the SQZ servers, so it won't be possible to go to LN3_SQZ until the issue is fixed.

We noticed that the green laser is particularly glitchy (Fig.1)

After a few failed lock attempt, we realized that a noise injection on SSFS driving was left on.

After turning it off the lock acquisition worked fine.

During this occasion, Masserot noticed a logic error in ITF_LOCK.py, lines 4310-11 (lines injection on SSFS). This version of Acl does not allow to send two consecutives commands to a Sum channel. We emporarily substituted them with a cm_send that changes both the weights of the two lines in SSFS.noise_driving_rtpc.

We leave the ITF in LN3

Yesterday morning we noticed a strange behavior of the Etalon loop, both on NI (fig. 1) and WI (fig. 2) tower, probably due to the restart of some ACL servers that generate the signal for the control loop while the loop was still ON.  

In particular, the loop seemed to have an inverted sign as it was heating the tower when the RH probe temperature was above the setting point. A stop/start of both loops (NI: 15h53m-UTC; WI: 17h57m-UTC) seemed to solve the problem (see fig. 3). However, as observed by Michal, it is possible that this huge and fast change of temperature of the two towers (fig. 4) had an effect on the lock stability and on the sensitivity.

Due to the slow control of the loop, the effect of the issue were visible with a huge delay; we then decided to postpone the start of the etalon scan, expected for the beginning of the ER. From the data of this morning, I would suggest not to start the scan before the end of the day in order to start with a stable initial state.

Beside, it is worth to notice also a strange behavior of the NI RH temperature probe. In figure 5 we can observe that after the lost of data due to the server restart of tuesday morning (between 7:10 and 8:30 UTC), the temperature read on the NI RH did a jump (and the same did the NI etalon err signal), while on the WI its behavior was as expected.  

In the last couple of days we performed several tasks on the Automation, in order to prepare it for ER16 and follow the changes on the ISC Acl servers.

The main tasks performed were:

• cleanup of the INJ_MAIN node: we removed the very old and outdated NOISE_BUDGET path, and the FmodErr LNFS Calibration routine, which was never effectively tested; we also removed the FmodErr tuning via the old loop in the MC DSP card, unused since O3;
• ARMS_LOCK/DRMI_LOCK: we followed the changes on the ISC Acl servers and removed any call to any removed channels; we also removed anything related to 25MHz/81MHz channels, which are going to be removed soon;
• a few spamming log.info calls during timers have been spotted and removed; now only the first call will be logged, the other ones only notified in the GUIs;
• ITF_LOCK: same as the last two bullet points, and in addition we removed everything related to the LF and LLF DARM lines and consequent OSs and DCPs, which have been removed; in addition, we moved the whole SR_TY misalignment routine from LOW_NOISE_3 to the end of ACQUIRE_LOW_NOISE_3; this will prevent from going any further before completion; as a consequence, now in LOW_NOISE_3 nothing really happens to the interferometer and the state can be safely used for Science operations; the V1:DQ_META_ITF_LN3_NOMINAL channel has been kept, in case we want/have to check data during the SR_TY misalignment, with a slightly different meaning:
  • -1: interferometer not in ACQUIRE_LOW_NOISE_3;
  •  0: interferometer in ACQUIRE_LOW_NOISE_3, everything has been set and SR_TY is the only thing moving (DRMI lines still on);
  •  1: interferometer in LOW_NOISE_3.

Some minor tasks will be done during ER16, the main ones being the removal of recent and less recents comments and the spotting of excessive logging/improving logging where needed. After this task and the completion of the cleanup of the userapps directory (which is in a much better shape already) we will finally cleanup the svn repository and produce a tagged snapshot for ER16.

This morning we proceeded with the cleanup and restart of the main ISC Acl servers (LSC_Acl, LSC_Acl_Moni, ASC_Acl and ASC_pre); the main goals of the activity were:

• remove several many channels, in order to reduce the number of channels sent and stored to the DAQ;
• reduce the load on rtpc20;
• perform a full restart of the ISC servers to be sure that their configuration had no overlooked pending modifications.

The activity was successful, with the only additional change that we do not acquire LSC_DARM_ERR anymore in ASC_pre in order to avoid a possible dependency loop among the processes (although we did, not exactly clear how we managed before); we acquire SDB2_B1_DC_D instead, which is the same but without an overall constant (calibration * loop gain * etc..); this has the only factual consequence that the ASC copy of the LSC is not giving information before DC readout, as there is no B1_DC; afterwards, the two probes become nearly identical, due to the fact that they are built as a ratio of two B1_DC demodulations, so the overall constant effectively cancels out. This takes some time due to the very low-passed nature of the probe, but this happens anyway before the ASC one goes in loop on SR_TY. The LSC_DCP_moni_mad_cal probe is unaffected by all of this.

We tested the lock acquisition a few times, to test the changes together with the changes to the automation and, after a couple of bug fixes, everything is working as expected.

In view of ER16 start, we have proceeded yesterday with a cold restart of the majority of ITF online processes. This has also be the occasion for finalizing the switching of /virgoApp , /virgo , /cvmfs to CVMFS native mounts which was already performed on the olnodes, ctrls and farmns machines.

This was the sequence of actions:

In the morning:

• DAQ (Collection, Storage, Access) and Automation nodes stop     
• stopping of all Cm Name Servers (Cascina, CascinaTest, CascinaLV, CascinaLVTest,  CascinaRD) and all VPM Servers (VirgoOnline, VirgoOnlineTest, LowLatencyAnalysis, LowLatencyTest, VirgoRD)
• NFS to CVMFS swap for:
  • rdserver1
  • rdserver2
  • olserver41 
  • olserver52
  • olserver53
  • olserver54
  • olserver55
  • olserver111 
  • olserver113 
  • stol01
  • stol02
  • stol03
  • stol04
  • stol05
• restart of all Cm Name Servers and VPM Servers
• restart of the DAQ chain and Automation nodes
• relock to CARM0 1F

In the evening: 

• stop of all remaining processes running on the rest of olservers (see list below)
• NFS to CVMFS swap for the rest of olservers
• restart of all remaining processes running on the rest of olservers
• relock to LN3

With this last set of machine we consider the transition to CVMFS native mounts in Cascina as completed.

----------------------------------------

• olserver37 
• olserver38 
• olserver40 
• olserver112 
• olserver114
• olserver115 
• olserver116 
• olserver117 
• olserver118 
• olserver119 
• olserver120 
• olserver121 
• olserver122 
• olserver123 
• olserver129 
• olserver130 
• olserver133 
• olserver134 
• olserver135 
• olserver136 
• olserver137 
• olserver138 
• olserver139 
• olserver140 
• olserver141 
• olserver142 
• olserver143 
• olserver144 
• olserver147
• olserver149

This morning the scope was to re-commission the scripts that inject noise on the LSC / ASC / SSFS loops. The LSC script was already ready, so we just run it to check that it was working properly. All the injections showed coherence with Hrec (SRCL wsa slighlty worse than the others, on Wednesday we would like to try a nosie injection at slightly lower frequencies 5-50Hz). The script can be found and launched at: /virgoDev/Automation/scripts/LSC/inject_lsc.py.  Today's injections GPS can be found at /virgoData/NoiseInjections/LSC/LSC_injection-1394783415. Notice that during these injections the Galvo of B4 QD1 opened. To be checked if it was a coincidence or if this happens consistently.

Next activity was to inject noise in the angular loops closed on QPD error signals (Commp, DIFFp and PR) in order to adjust the amplitudes of the noise injected. Note that BR TX loop is also measurable but we mispelled the DOF name in the function to perform the injection (to be repeated on Wednesday)

Clean data: Same for the LSC noise injections.
ASC noise shape = Butterworth bandpass between 5 and 50 Hz.
GPS time stamps of the injections:
- 8.21.15 UTC + 120 sec, DIFFp TX inj ampl 8e-6.
- 8.32.10 UTC + 120 sec, DIFFp TX inj ampl 1e-4.
- 8.55.00 UTC + 120 sec, PR TX inj ampl 1e-4.
- 9.06.15 UTC + 120 sec, PR TY inj ampl 2e-4.
- 9.22.30 UTC + 120 sec, COMMp TX inj ampl 9e-4.
- 9.33.40 UTC + 120 sec, COMMp TY inj ampl 1e-3.

We also wrote a symmetric code in order to inject noise in these loops, and we tested it. It can be found at: /virgoDev/Automation/scripts/ASC/inject_asc_test.py. The .txt file with the measurements is stored in the folder 'virgoData/NoiseInjection/ASC/ASC_injection-*GPS*.txt'. We would like to finish with the BS TX on Wednesday, and then inject noise through the driving to the remaining angualr DOFs (SR and softs).

As side activity we performed an OLTF measurement of the BS TY loop through the DSP (HF brench, optical lever sensing), in order to have a response of the roll-off of the loop tf.
Noise shape: bandpass 'bpass.flt' centered at 3.5 Hz.
- 9.54.30 + 120 sec, BS TY inj ampl 5e.3
We tested again the control filter for BS TX tested last thursday. This time, it was possible to appreciate the effect of the filter (gain more at 200 mHz). GPS of the test:
- 10.36.00 + 120 sec, clean data with standard filter.
- 10.39.30 + 120 sec, test with new filter (txCorrAA2.flt).
We left the new filter as default. In Fig.s 1 is reported the measurement of the HF brench of the open loop of the BS TY, while in Fig.2 is plotted the spectra with the response of the new control filter for BS TX (red) with respect the current one (blue).

FInally, we tried to inject noise to the SSFS. The first thing we did was to comment the "define SSFS_FLT_NOISE" in order to be able to change the filters online, and then we restarted SSFS_phi, SSFS_noise and SSFS_Ctrl. We relocked and we started to try to make nosie injections. After some trials, we managed to inject noise around the UGF, and we already created a dedicated script that can be found: /virgoDev/Atomation/scripts/LSC/inject_ssfs.py. On Wednesday we would like to add two more dedicated noise injections at lower frequencies.

We will work on the script to produce the noise budget online.

The aim of the shitf was to reduce the thermal transient between the lock acquisition and carm null.

In particular, we had noticed that the change in the optical gain of the DIFFp was too high and the servos were not fast enough to compensate for it (as in the 1st plot, which shows a lock acquisition of yesterday night in which the DIFFp TY gain increases from 0 to 50 in 2 minutes). To minimize this effect Ilaria tuned the CHs (1st part of the shift).

CH to minimize the changing in the DIFFp gain @CARM 0 1f:

- the starting values were:

WI CH: 51 mW

NI CH:  115 mW

At 08.17 UTC, the CH power change (-10 % on both CH powers) has been completed in CITF:

WI CH: 46 mW

NI CH:  104 mW

At 08.40 UTC, we resumed the lock acquisition to see the effect in CARM NULL1F. We noticed that the excursion in the gain has decreased and the transient time has increased, as seen in fig. 2.

We thus left these CH power values.

The second part of the shift was devoted to the increase of the amplitude of the DARM line at 74.4Hz, since we found out that the SNR of the OS is very low and the SRCL SET oscillates.

Increase of the DARM LINE at 74.4Hz by a factor 2

• We started by opening the SR TY and SRCL SET loops (since the calibration of the DCP and OS are based on the DARM line and would change with its amplitude).
• We increased the DARM line amplitude from 2.5e-8 to 5.0 e-8
• We recalibrated the DCP signal  both in ASC and LSC processes from 36.4 to 72.8(LSC_MONI.DCP_cali and ASC_pre.DCP_Cali) and closed again the SR TY loop
• We recalibrated the OS, os_cali_science in the ini file, from 35700 --> 7140 (LSC_NArm_B7_OS_I_Hz.NArm_B7_OS_i= 7140) and closed again the SRCL SET loop but with a lower gain srcl set weight from 1 to 0.5 (LSC.SRCL_SET_INPUT.OS_LF_Hz_SIGN=0.5)
• we wanted to try the whole lock acquisition but we unlocked twice in LN2 (unlocks probably due to the NE, similar to the one spotted in 63540 and 63506)

The function to scan the Etalon 2D has been made. The NI will make a ramp and the WI a sine (with a frequency 7 times higher). The test is visible in figure 1.

def Etalon_2D_scan(amplitude,duration):
    frequency = 1./duration
    frequencySin = 7*frequency
    amplitudeSin = 0.5*amplitude
    cm_send('LSC_Etalon_Acl','AcRampChSet','NI_ramp_noise',float(frequency),1.0,0.0)
    cm_send('LSC_Etalon_Acl','AcSinChSet','WI_sin_noise',float(frequencySin),1.0,0.0,0.0)
    cm_send('LSC_Etalon_Acl','AcSumChSet','NI_NOISE',1.0, 1.0,'NI_ramp_noise','load')
    cm_send('LSC_Etalon_Acl','AcSumChSet','WI_NOISE',1.0, 1.0,'WI_sin_noise','apply')       
    cm_send('LSC_Etalon_Acl','AcSumChSet','NI_RH_SET_NOISE',1.0, 1.0,'NI_RH_SET', float(amplitude),'NI_NOISE','load')       
    cm_send('LSC_Etalon_Acl','AcSumChSet','WI_RH_SET_NOISE',1.0, 1.0,'WI_RH_SET', float(amplitudeSin),'WI_NOISE','apply')

def Etalon_2D_scanOFF():
    cm_send('LSC_Etalon_Acl','AcRampChSet','NI_ramp_noise',0.0,0.0,0.0)
    cm_send('LSC_Etalon_Acl','AcSinChSet','WI_sin_noise',0.0,0.0,0.0,0.0)
    cm_send('LSC_Etalon_Acl','AcSumChSet','NI_NOISE',1.0, 0.0,'NI_ramp_noise','load')
    cm_send('LSC_Etalon_Acl','AcSumChSet','WI_NOISE',1.0, 0.0,'WI_sin_noise','load')     
    cm_send('LSC_Etalon_Acl','AcSumChSet','NI_RH_SET_NOISE',1.0, 1.0,'NI_RH_SET', 0.0,'NI_NOISE','load')       
    cm_send('LSC_Etalon_Acl','AcSumChSet','WI_RH_SET_NOISE',1.0, 1.0,'WI_RH_SET', 0.0,'WI_NOISE','apply')

The values to be used in the ER are :

Amplitude = 0.4 duration = 604800

The aim of the shift was to bring back the DCP monitor on the DARM line at 74.4 instead of the 33 Hz, and switch it off.

• We opened the SRCL SET loop and we brought it out from zero to compare the calibrations of the optical spring. However, we realized that both of the signals were insensitive to the applied offset. We thus decided to increase again the DARM LINE (which had been lowered on the 15th of Feb., see #63294). With the line higher, the error signal becomes sensitive to the OS, as it can be seen in figure 1. We then came back to using the old OS error signal (srcl_set_weight = 1, srcl_set_weight_llf = 0) and turned off the 33Hz line.
• due to this issue we decided to adopt a new strategy in LN3, to ensure that the OS is good while the SR TY is being misaligned.
  • We start with the DARM LINE at 74,4Hz amplitude at 1e-7, and the corresponding calibrations for the OS and DCP (os_cali = 7140 and dcp_calib=148). The SRCL SET is enabled while the SR TY is being misaligned. Once it reaches its nominal position to have a dcp set = 170 we lower the DARM LINE AMPLITUDE by a factor 4 (2.5e-8, as usual), we apply the corresponding calibrations os_cali_science  = 35700 and dcp_cali_science=36.4 and we open the SRCL SET loop (lines 6237 to 6241 in ITF_lock.py). We can see this new procedure in figure 2, which has been tested in the automation already.

Preamplifier swap

We made the swap of the preamplifier, located between the output of the fibered EOM and the injection of the SL.

We installed the 2W amplifier from Lumibird we use for the ALS prototype, which has been previously characterized in the optics lab. It is seeded with 14.9dB (coming from the fibered eom). The output has been set to have the same power as before (i.e. 0.2 W on the ML DC photodiode), a further trial could be to increase it.

We had to decrease the gain of the IMC loop (attenuation increased by 1dB, from 19 to 20 dB) in order to have the proper OLTF (UGF at 107kHz with a phase margin of 16deg).

We had some troubles to relock the ITF (we could relock only after having misaligned the SR TY by +0.8 in carm0 1f to lower the B1p DC power and be able to lock the OMC). The first lock in LN3 after the swap of the preampli has been reached at 20:39:59 UTC.

Plots 1 and 2 show the spectra @ carm null 1f and LN3 (it seems slightly better between 1-3 Hz).

Scan of the IMC longitudinal wp in LN3

The longitudinal working point of the IMC is currently set to -0.03V. We made a scan from 0.5 to -0.5V in 300 s starting from 21:25:27 (plot 3). The amplitude of the 1111Hz has been increased to 0.5V in order to be able to generate the signal INJ_PMC_TRA_DC_FMOD_COUPLING (PMC transmission demodulated @1111Hz)

The shift was dedicated to verify the effect of the NE RH power change performed in the morning (63405).

At 15.45 UTC the ITF again reached LN3. The lock acquisition went well.

The situation after the NE RH thermal transient was unclear. The cavities' power and the sidebands were a little bit lower than the morning and the MICH set was increasing significantly.

Thus, at 17.36 UTC the NE RH power change done in the morning has been reversed: we increased the NE RH power from 4.5 W (12.94 V) to 4.7 W (13.2 V).

The MICH set immediately began to decrease and the sidebands and the cavities' power to grow. We noticed also that the BS offset (used to minimize the CMRF) also decreased, getting very close to 0.

The thermal transient is still ongoing. 

The ITF main signals during the shift are shown in fig.1.

The task of the shift was to make the whole lock acqusition with the SR ty close to the final position (~200Hz of DCP) in order to avoid the transient at LN3 which will detune the optimal tuning for the controllers.

We observed that this could not be done if the SR ty initial position is in the wrong side of the "Parabola". If this case happens the servo will bring the SR ty further away. Then for sure we have to start from the aligned position.

The automation has been restored in the normal configuration.

In any case other ideas to have the science mode with the optimal tuning are present and will be implemented next week.

This morning we continued and completed the recovery of the ITF lock up to Low Noise 3.

Low noise 3 reached a first time at 08h27 utc.

We use these data from 08h27 to 08h29 to check the blending of the B1s photodiode (see Fig.1 and Fig.2). The blending seems OK.

We had some data with stable BNS range around 52-53 Mpc from 09h00 up to ~09h35 utc (Figure 3).

During the previous lock acquisition we realized that we had forgotten to restore the B5 QD2 offsets used for dark fringe. This was done at next unlock, at 10h36 utc.

FbsDet: Remove SMS SDB2_dbox_bench, reload Config at 10h42 utc to recover SMS data produced by this process.

With Michal we changed some logic in DET_MAIN node in order to fix the issue with DET_MAIN node getting stuck in the state "SHUTTER_READY_FOR_CLOSING" when B1s safety is triggered (https://logbook.virgo-gw.eu/virgo/?r=63361):

• The SHUTTER_READY_FOR_CLOSING state has been removed ; instead we now directly go from SHUTTER_OPEN to SHUTTER_CLOSING state.
• We added the state SHUTTER_CHECK_CLOSED between SHUTTER_CLOSING and SHUTTER_CLOSED.
• In the class SHUTTER_CLOSING we have removed the check on B1s photodiode being enabled, and we have removed the check on the power on B1s and B1 during the closing of the shutter.

The DET_MAIN node has been loaded without issue.

ITF unlocked during lock acquisition from step 115 (transition of the DARM hand-off to B1_PD3) at 10h55m48 utc. Figure 4 shows that DET_MAIN wend to DOWN at the time of the unlock and then worked properly, renabling the B1s photodiode when passing through SHUTTER_CHECKED_CLOSED.

Opening and Closing of OMC shutter tested successfully with ITF in DOWN around 10h59 utc.

With ITF in DC readout: we adjusted the B1 demodulation phase for the OMC lock: changed from -0.64 to -0.40 rad at 12h11 utc.

Low Noise 3 reached at 12h18 utc (Figure 5), and interrupted manually at 12h43 utc to allow an activity on the automation.

Figure 6 shows what happened when the lock was interrupted: DET_MAIN passed correctly from the state "SHUTTER_CLOSED" to the state "SHUTTER_CLOSING", before going to DOWN. B1s safety was triggered when DET_MAIN was in SHUTTER_CLOSING, but the photodiode was reactivated  in SHUTTER_CHECKED_CLOSED and DET_MAIN eventually made it to SHUTTER CLOSED.